fix(components): combobox honours options[].disabled - #8142

Fixes #7687

What was wrong

options[].disabled on a combobox node was declared (@object-ui/types ComboboxOption.disabled), validated (ComboboxOptionSchema in the zod mirror, pinned as boolean on both faces by the objectui#7087 twin-symmetry ruling) and never read. The component mapped each option to a CommandItem carrying key, value and onSelect only, so an option authored { value, label, disabled: true } passed safeValidateSchema, type-checked against the published ComboboxSchema, and rendered as an ordinary, fully selectable option.

Reproduced before touching anything — the pin in this PR, run against the base tree 5b09821ed, fails exactly there:

× marks an option authored `disabled: true` as disabled in the DOM
    Expected the element to have attribute: data-disabled="true"
    Received:                               data-disabled="false"
× refuses to select a disabled option — no onValueChange
    expected "vi.fn()" to not be called at all, but actually been called 1 times
    1st vi.fn() call: Array [ "beta" ]

The fix — one prop, the house spelling

disabled={option.disabled} on the CommandItem, which is what the sibling select renderer already does on its SelectItem (packages/components/src/renderers/form/select.tsx). The styling needed no work: the CommandItem wrapper's className already carried data-[disabled=true]:opacity-50 and data-[disabled=true]:pointer-events-none, so only the read was missing.

Remedy chosen: honour the key, not retire it. Retiring disabled from ComboboxOption and the zod mirror would narrow a published surface and would require the objectui#7087 twin-symmetry pin to be changed; honouring it restores declared = enforced for the cost of one prop. No declared type or value moves — ComboboxOption and the zod mirror are exactly as they were; the only packages/types file in this diff is a census test, described below.

Measured: the onSelect guard would have been dead code

The card left open whether cmdk needs a refusal inside onSelect in addition to the disabled prop. Measured against cmdk 1.1.1 rather than assumed — a disabled Command.Item:

• renders with onClick undefined, so a click reaches no handler;
• never registers the cmdk-item-select listener that Enter dispatches;
• is excluded from the valid-item selector the arrow keys and the auto-select walk use (aria-disabled="true" is filtered out).

So the prop alone suppresses selection on both the pointer and the keyboard path, and an extra guard in onSelect would be unreachable. It is not added. The reasoning is recorded at the change site so the next reader does not re-open the question, and the behaviour legs of the pin are what keep the measurement honest.

The pin asserts behaviour, not just the attribute

⛔ An attribute-only pin passes on "styled disabled but still clickable", which is the exact failure this card is about. packages/components/src/__tests__/combobox-option-disabled.test.tsx has five legs:

The two controls exist because both negatives are vacuous without them — a popover that never opened would satisfy "not called" just as well.

Reverse verification, run from the committed state (mutation proven on disk by a marker count 1 → 0 and a blob-hash mismatch against the HEAD blob, restored with git checkout HEAD -- ... and proven clean by an empty git diff HEAD): removing the one-line read turns all three assertion legs red and leaves both control legs green. That is the shape it has to have — the controls measure the surrounding machinery, not the fix.

The docs row, and the census that claims it

content/docs/components/form/combobox.mdx documented ComboboxOption as value-plus-label, missing disabled. Only that interface block is touched; the rest of the page is untouched, and content/docs/releases/ is not touched at all.

⚠️ Correcting a belief this card carried. The card recorded that the block's plaintext fence means no CI gate could see it. That is true of the doc-TYPE gates — check-doc-component-types reads only type string literals, and check-doc-snippet-types compiles ts/tsx fences, not plaintext — and false overall: packages/types/src/__tests__/component-docs-disabled-inherited-7239.test.ts is a census that reads those .mdx files as text, counts every documented disabled?: row, and pins the population. It caught the new row, red, on Test (shard 4/4).

So the second commit claims the row deliberately. ⛔ Not a count bump: the row is classified on the criterion that file states — the shipped ComboboxOption declares disabled itself and does not extend BaseSchema, so it is INDEPENDENT and the narrow boolean spelling on the page is the correct one. Counts move consistently: rows 22 to 23, independent 8 to 9, inherited unchanged at 14. A new ## Amendments section in that file records why the ledger moved, so a later reader can tell a deliberate claim from a number bumped to get back to green.

@object-ui/types is deliberately not given its own changeset bump: no shipped type or value moves there, only that test.

Why minor

Making a previously ignored key take effect is a user-visible behaviour change. An author who already writes disabled: true today gets a different combobox after this lands. The changeset body says so and records why the retire remedy was not taken. (major is forbidden in this repo; a deliberately breaking change ships minor.)

Gates

Re-run at b0a6b3c8b, after the census fix.

The doc-reading population above was enumerated by measurement (grep for the tests that read content/docs) rather than guessed, because a scope narrowed to the package the code fix lives in is exactly what could not see the census failure. A full local pnpm test does not fit the container's foreground limit — it is a 4-way shard job on CI — so that enumeration is the declared substitute.

Known reds that are not from this branch: Live E2E (informational) is advisory and red on main itself (carded objectui#8084), and a Build and E2E death at roughly 11s at pnpm --version is a corepack download flake.

Scope

⛔ No change to the declared surface: ComboboxOption, ComboboxOptionSchema and the objectui#7087 twin-symmetry pin are untouched (narrowing them is the retire remedy's territory). ⛔ Not folded into objectui#6349 batch 3 / PR #7691, which deliberately changes no behaviour. ⛔ objectui#7697, the root-barrel export gap, is adjacent and surface-only and is not addressed here — it stays open.

Out-of-scope finding filed unassigned while working this card: objectui#8140 — the combobox renderer never reads ComboboxSchema.defaultValue, .name or .description, while the sibling select and input renderers read theirs. Same defect class, different member set, deduped against a search whose control fired. ⛔ Not fixed here.

⛔ Left as a draft deliberately: CI convergence and landing belong to the dispatching PM.